Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make compiler hint to import unqualified types/values #4304

Open
wants to merge 4 commits into
base: main
Choose a base branch
from

Conversation

mine-tech-oficial
Copy link

@mine-tech-oficial mine-tech-oficial commented Mar 5, 2025

This PR closes #4297

  • Show hint to import unqualified types
  • Show hint to import unqualified values
  • Consider the type's arity
  • Consider the value's arity

Currently the way it decides which module to hint is by preferring imported modules over importable ones, and sorting by name length.

@mine-tech-oficial
Copy link
Author

The hints should be done now, although I don't if its possible to find the arity (suppose someone wrote Dict, mentioning dict.Dict, but didn't put the types, which the code would recognize as "nullary"). Also, the current code for suggesting modules to import also doesn't take the arity into account.

@mine-tech-oficial mine-tech-oficial marked this pull request as ready for review March 6, 2025 13:22
Copy link
Member

@lpil lpil left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you! I've added some comments inline, and snapshot tests will need to be added to test all the new paths through the code.

It would be great to also check the arity of the constructors. Suggesting a zero-arity Wibble when it is being used in a way that takes 2 arguments would be unhelpful.

// Don't suggest importing modules if they are already imported
_ if self
.imported_modules
.contains_key(importable.split('/').last().unwrap_or(importable)) =>
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There's no fixed relationship between the name used once imported and the name of a module, and this code will produce the same name for multiple modules, so this doesn't successfully skip over already imported modules.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

To be fair I had just copied that line from the suggest_modules function in the environment module, think it'd be correct. I think I should remove the later code where it adds the imported modules to the suggestions vector, although I don't know how I'd detect if a module is imported or not

if is_type {
format!("Did you mean to import `{module}.{{type {name}}}`?")
} else {
format!("Did you mean to import `{module}.{{{name}}}`")
Copy link
Member

@lpil lpil Mar 10, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't want to encourage unqualified importing of values. Perhaps we should only make these suggestions for types and record constructors.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Okay! Tying with my point below, we could write the "generic" value case as "Did you mean to reference module.{value}" and, in case it isn't already imported, "Did you mean to import module and reference module.{value}". What do you think?

@@ -23,3 +23,4 @@ error: Unknown type
The type `Wibble` is not defined or imported in this module.
There is a value in scope with the name `Wibble`, but no type in scope with
that name.
Hint: Did you mean to import `module.{type Wibble}`?
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the ` should be before the import keyword?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think if we make the "import" part of the "code" section (between backticks), it should probably be written "Did you mean to write code here". What do you think?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actually, the current code for module suggestions (in the qualified case) says "Did you mean to import module", so how it is right now should be more consistent

@@ -2326,7 +2331,7 @@ but no type in scope with that name."
Diagnostic {
title: "Unknown variable".into(),
text,
hint: None,
hint: suggestions.first().map(|suggestion| suggestion.suggestion(name, false)),
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There's a vector of suggestions, but only the first one is used. Seems like only one should be given in that case.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I thought this was fine, as that is what the current code for module suggestions does. Anyway, I'll change it!

}

impl TypeOrVariableSuggestion {
pub fn suggestion(&self, name: &str, is_type: bool) -> String {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Never use bools as arguments please 🙏 This could be a Layer.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

To be frank, I did think that bool wasn't a good fit, although I didn't know what to name the Enum as. Thanks!

@lpil lpil marked this pull request as draft March 10, 2025 12:58
@mine-tech-oficial
Copy link
Author

The code should now consider arity, but it is an Option as I don't think it is possible to find the arity in all cases.

@mine-tech-oficial mine-tech-oficial marked this pull request as ready for review March 10, 2025 23:13
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Show hint to import unqualified types/values
2 participants